Writing a screenplay, a book, or any other document is a process that usually requires a significant time investment from the people responsible for producing such a document. The quality and value of the document that is ultimately generated typically increases when multiple people have had the opportunity to review and comment on the document. As a result, the process of reviewing documents is tightly integrated into many aspects of modern business.
The first draft of a document often contains mistakes or other problems that should be corrected. These issues are typically resolved during the review process. Anybody that can provide valuable input about the document may contribute to the review process. During this process, the reviewer may, for example, wish to provide input about the contents of the document by giving comments, feedback, and/or making changes to the text of the document. In some instances entire portions of the document are deleted or rewritten. In other instances, portions of the document are simply critiqued. The document that is ultimately produced when the review process is complete may be very different from the document that existed in first draft form. Thus, the review process is a valuable step in the process of finalizing a document.
Since the people who are largely responsible for reviewing documents often have a schedule that keeps them moving from one meeting to another, there is a need for a device that simplifies the review process by allowing a reviewer to interact with the document while on the move. For example, current systems do not allow the reviewer to access and verbally comment on a document from multiple locations. A reviewer cannot use current systems to begin reviewing a document from a cell phone in the reviewer's car, continue to review the same document from a home PC, and finish reviewing the document from a pay phone.
Current systems also do not provide the reviewer with an intuitive way to verbally interact with the document. Most systems for reviewing documents are text-based and do not have the ability to read the document to the reviewer so that the reviewer can hear the contents of the document. Moreover, these text-based systems do not provide a way to record verbal comments provided by the reviewer while the document is being read. These limitations become particularly evident when the document being reviewed is a movie script or some other kind of document where it is important for the reviewer to hear the words contained in the document.
So that the reader can better understand the advances in the art made by embodiments of the invention, a brief discussion of several current systems for editing and/or commenting about a document follows. Some text-based systems (e.g., word processors) provide a way for reviewers to comment on a document by manually typing an entry into a comment field. Comments can also be recorded in a sound file and manually associated with the document. However, this process is laborious and does not provide the reviewer with a way to easily hear and comment upon a document.
Some word processing programs (e.g., Microsoft Word™) have a built in mechanism for inserting comments into a document. This mechanism does not provide reviewers with a way to listen to audio output associated with the contents of a text document. Nor do such programs allow the reviewer to provide input about the document by speaking to the word processing program. However, such word processing programs do supply reviewers with a way to manually insert typed comments into a text document.
FIG. 1 illustrates a word processing program configured to insert comments into a document. Word processing program 100 contains an instance of document 112 containing text about which the user of the program may comment. If the user wishes to comment on sentence 104, the user may insert comments into the document by utilizing a pointing device (e.g., a mouse) to highlight the text that is to be associated with the comment. Once the text is selected the user inputs the comments via an input device such as a computer keyboard. The comments are typically entered in a comment region 102 that consists of a list of one or more comments associated with document 112.
The user who authored the comment is identified in an abbreviated manner in a location related to the comment. User ID 110, for example, indicates that a user having a username (e.g., user1: jake_smyth) is associated with comment 108. Comment 108 may exist as a textual comment or as an audio file. If a verbal comment was recorded and associated with document 112, the user may elect to listen to the verbal comment by selecting icon 106. Upon selection of icon 106, audio player 112 plays the audio file containing the stored version of the verbal comment. In some word processing programs, the text that is related to comment 104 is highlighted with a color that indicates a comment was made about that portion of text.
Although word processing programs provide a built-in mechanism for typing comments into a document such programs do not provide a way to insert comments into the document from a place other than the program itself. For example, a user cannot comment about the document unless the user is utilizing the word processing program and has a copy of the document on-hand. Thus, there is a need for a method and apparatus that complements existing word processing programs by providing users with alternative avenues for editing or commenting on a document while on the move. Moreover, such word processing program lack an efficient way to store and easily retrieve documents from any location once annotations are made to the document. For example, existing systems do not have a way to that allows the user to continuously access and make comments to the document.
Another example, of an existing system for editing documents can be found in Boys, et al. (U.S. Pat. No. 5,875,448). The Boys, et al. patent describes an audio editor that operates on a file that may contain text and voice data in separate regions. The audio editor described in Boys et al., provides functions for entering voice data, and also for editing the entered voice data. Once such voice data is entered and edited that data is passed to an individual for conversion into a text file. Files can be uploaded from the audio editor to a PC application for converting the file entirely to text, providing a system wherein all variable entry and editing can be done verbally, and conversion to text is left as a final chore.
FIG. 2 illustrates a representation of a data file as used in the audio editor described in Boys, et al. Data file 200 is created by the audio editor or some other digital device and downloaded to the audio editor. The file typically consists of digitally recorded voice data entered via a microphone or some other audio input. However, in some instances the data file supplied to the audio editor may have machine operable text code, as in a PC word processor file, and other portions that are digitally recorded voice. The dual nature of the data file is important because the final desirable form of a file is machine-readable code (e.g., a finished word-processor document). Thus, the nature of data file 200 is a formatted word processor file having sections wherein data may be added and edited as digitally recorded voice. This formatted file 200 contains sections such as headers, footers, subheads, (e.g., elements 202, 204, 206, 208, 210, 212, and 213) that cannot be edited by the audio editor because they are machine operable-text code. Boys, et al. does contemplate the use of text-reading software to render elements 202, 204, 206, 208, 210, and 212 as synthetic speech. The text-reading software provides users with a way to review all parts of the file 200, but the user “may only enter, add to, and edit the digitally-recorded audio portions” (See Boys, et al., Column 9, lines 4-5). In between elements 202, 204, 206, 208, 210, and 212 file 200 contains portions 59, 61, 63, 65, 67, and 69. These portions are reserved for digitally recorded voice. Thus, file 200 may contain both text portions (referred to as machine-operable text code) and digitally recorded audio portions. When the user selects a play button both the text portion and the audio portion are vocalized. The user may then forward or rewind the file to hear different portions vocalized. Thus, the audio editor provides users a way to create and edit a file before converting the file entirely to machine-operable code (e.g., text).
Once the user has finished creating the file it may be uploaded to a host computer such as a PC and converted into text. An operator does the final conversion using a word processing application. The word processing application displays file 200 in a manner that shows the text and vocal portions of the file. The operator may listen to the vocalized portions by selecting such portions with a mouse or other pointing device. The operator may then enter the vocalized data as text as it is recited.
There are multiple problems associated with the approach utilized in the Boys et al. reference. Boys et al., for example, does not provide a mechanism for verbally editing all aspects of the file (e.g., elements 200-213) cannot be edited. Boys et al. discloses a mechanism for editing the audio portions of file 200, but does not provide a way for the user to edit or comment on text elements in the file. Boys et al. is directed to creating and subsequently editing audio files that are inserted into a template file containing elements that cannot be edited. Thus, Boys, et al. limits the operations of the user by restricting the elements that can be edited. Moreover, Boys et al. does not distinguish between vocalized input that is intended to be a comment or annotations. Rather Boys, et al. provides a way to add or makes changes to a document, but the user cannot flag certain portions of input as general comments. Another limitation inherent in the design utilized in Boys et al. is that the audio portions of the file must be manually converted into text via an operator. Boys et al. does not have a mechanism in place for automatically converting or aiding the user in the editing process. Boys et al. also lacks a mechanism for selectively listening to comments made by a particular user. In Boys et al., if two people edit the same document, the system does not distinguish between the parties and provide users a way to selectively listen to the comments of one party or another. Rather, the audio editor is intended to aid a single user in the creation and editing of a single file. The audio editor is used to generate documents not comment on an existing document without necessarily modifying the contents of the document itself. A further limitation in current systems is that such systems are not directed to providing documents to users in any location. Users of the audio editor described in Boys et al. cannot, for example, obtain a document from a remote location without having an instance of the document on-hand.
Thus, there is a need for a system that solve the limitations inherent in the prior art by allowing the user to listen to a document and verbally comment on the contents of the document without necessarily changing the document. Moreover users could benefit from a system that aids the user responsible (e.g., the typist or data entry person) for the conversion process. In some instances there is also a need for a system that allows user to selectively listen to comments made by a certain individual without having to review all comments that were made about the document.
In the foregoing discussion about current systems, the problems and limitations set forth as existent in the prior art are provided for exemplarily purposes. It should be clear to one of ordinary skill in the art that these problems also exist in other contexts or professions and that the invention may apply to situations other than the ones described herein.